Add basic tool infra and complete registerTool()#113
Add basic tool infra and complete registerTool()#113domfarolino wants to merge 3 commits intomainfrom
registerTool()#113Conversation
| : <dfn>description</dfn> | ||
| :: a [=string=]. | ||
|
|
||
| : <dfn>input schema</dfn> |
There was a problem hiding this comment.
Is there a particular reason this is being stored as a string in the tool map, and not an object? It seems like this is an optimization for passing the schema to an LLM, but here in the spec we'll likely have algorithms that need to retrieve the original object and read from it (e.g. input validation, listTools).
| }; | ||
| </xmp> | ||
|
|
||
| Each {{ModelContext}} object has an associated <dfn for=ModelContext>internal context</dfn>, which |
There was a problem hiding this comment.
What is the internal context for?
There was a problem hiding this comment.
The ModelContext IDL definition is just a web-exposed JavaScript interface, and so to store internal state associated with it (like the tool map from string => tool dfn), we need some internal data structure attached to it. Right now the only thing we really need to store associated with a given ModelContext interface is a tool map, but we'll need more state as well like things that track the current tool execution/pending executions, and possibly more. So I'm creating a general "internal context" bag for all of this stuff for now, and stuffing the tool map in it. This is a pretty common pattern for web specs in general.
4 participants
This PR adds some basic tool infrastructure and fills out the
registerTool()method properly. After this PR, I will upload follow-ups forunregisterTool()and more infrastructure to expose/verbalize tools definitions to a model (much will be implementation-defined, since we're not defining the actual protocol through which this is carried out), and handle tool execution.